⚠️ Potential issue | 🟡 Minor

Remove unused variable total_deps.

The variable is computed but never used. As flagged by static analysis.

-            total_deps = len(result.dependencies)
-            if args.dev:
-                total_deps += len(result.dev_dependencies)
-
             print(f"\n{file_path} ({result.package_manager.value}):")

In cortex/import_cli.py around lines 112 to 114, the variable total_deps is
computed but never used; remove the unused variable and its related increment
(delete the two lines that assign and modify total_deps) or, if a dependency
count is intended, replace its usage by actually using total_deps where needed
(e.g., in progress/output). Ensure no remaining references to total_deps remain
to avoid NameError.

⚠️ Potential issue | 🟡 Minor

Rename unused loop variable.

The line_num variable is not used in the loop body.

-            for line_num, line in enumerate(f, 1):
+            for _line_num, line in enumerate(f, 1):

Or simply:

-            for line_num, line in enumerate(f, 1):
+            for line in f:

In cortex/requirements_importer.py around line 243, the for-loop declares an
unused variable named line_num; rename it to _ (or _line_num) or remove it
entirely so the unused variable warning is resolved; update any references if
later used, otherwise iterate as for _, line in enumerate(f, 1): or simply for
line in f: to keep semantics identical.

⚠️ Potential issue | 🟡 Minor

Rename unused loop variable.

Same issue as GemfileParser - line_num is not used.

-            for line_num, line in enumerate(f, 1):
+            for line in f:

In cortex/requirements_importer.py around line 401, the enumerate loop uses an
unused variable named line_num; rename it to _line_num or simply _ to avoid
unused-variable lint warnings and clarify intent (e.g., for line enumeration
that doesn’t use the index, change "for line_num, line in enumerate(f, 1):" to
"for _, line in enumerate(f, 1):" or "for _line_num, line in enumerate(f, 1):").
Ensure no other references to line_num remain.

⚠️ Potential issue | 🟡 Minor

Annotate class variable with ClassVar.

PARSERS is a mutable class attribute and should be annotated with typing.ClassVar to indicate it's not an instance attribute.

+from typing import ClassVar, Dict, List, Optional, Tuple, Type

 class RequirementsImporter:
     """Main class for importing and installing dependencies."""

     # Mapping of file names to parsers
-    PARSERS = {
+    PARSERS: ClassVar[Dict[str, Type]] = {
         'requirements.txt': RequirementsParser,

In cortex/requirements_importer.py around lines 453 to 461, the PARSERS mutable
class attribute should be annotated as a ClassVar; update the declaration to
something like "PARSERS: ClassVar[Dict[str, Type[BaseParser]]]" (replace
BaseParser with the actual parser base class name used in the module) and add
"from typing import ClassVar, Dict, Type" to the imports if not present; leave
the dictionary value exactly the same but ensure the type annotation marks it as
a class-level variable.

⚠️ Potential issue | 🟡 Minor

Prefix unused variable with underscore.

The message variable is unpacked but never used. Prefix with underscore to indicate intentional discard.

-            success, message = importer.install(result)
+            success, _message = importer.install(result)

In tests/test_requirements_importer.py around lines 580 to 598, the test unpacks
the return of importer.install(result) into success, message but never uses
message; change the unpack to success, _message (or success, _ ) to indicate the
variable is intentionally unused and update the variable name in that assignment
only.

⚠️ Potential issue | 🟡 Minor

Prefix unused variable with underscore.

Same issue as above - message is unpacked but not used.

-            success, message = importer.install(result)
+            success, _message = importer.install(result)

In tests/test_requirements_importer.py around lines 600 to 615, the test unpacks
the tuple returned by importer.install(result) into (success, message) but never
uses message; change the unpack to (success, _message) or (success, _) to mark
the variable as intentionally unused (or rename to _message) so linters don't
complain, keeping the rest of the test the same.

⚠️ Potential issue | 🟡 Minor

Remove unused capsys fixture or use it for assertion.

The capsys fixture is declared but never used. Either remove it or add assertions on captured output.

-    def test_verbose_mode(self, capsys):
+    def test_verbose_mode(self):
         importer = RequirementsImporter(verbose=True, dry_run=True)

Alternatively, if you want to verify verbose output:

def test_verbose_mode(self, capsys):
    importer = RequirementsImporter(verbose=True, dry_run=True)
    # ... existing code ...
    captured = capsys.readouterr()
    # Add assertions on captured.out if verbose mode prints anything

In tests/test_requirements_importer.py around lines 714 to 725 the test function
declares the capsys fixture but never uses it; either remove the unused capsys
parameter from the test signature, or if you want to assert verbose output, keep
capsys and after importer.install(result) call capsys.readouterr() and add
assertions against captured.out (or captured.err) to verify expected verbose
messages; update the test accordingly and run tests to ensure no unused-fixture
warnings.

Missing test coverage for Dependency.__str__() when the version contains operators (e.g., ">=2.0.0", "~=1.0"). The current tests only cover exact versions ("2.0.1") and no version. Since the parsing logic stores versions with operators (as confirmed by test_parse_with_versions line 75-76), the __str__ method should be tested with these cases to catch the bug where it would produce invalid strings like "package==>=2.0.0".

The regex pattern r'^([a-zA-Z0-9_-]+)\[([^\]]+)\](.*)$' for parsing extras doesn't properly handle package names with dots (e.g., zope.interface[test]). The character class should include dots: r'^([a-zA-Z0-9_.-]+)\[([^\]]+)\](.*)$'. This inconsistency exists because line 129 correctly allows dots in package names, but line 121 doesn't.

The test test_gemfile_complex_syntax only verifies that 2 gems are parsed (line 712) but doesn't validate that the version constraints are correctly captured. Given the bug in the parser where only one version constraint is captured for gems with multiple constraints (e.g., gem 'pg', '>= 0.18', '< 2.0'), this test should be enhanced to verify the version field contains the expected constraint information.

The go.mod parser checks for the exact string '// indirect' in the line to skip indirect dependencies (line 433). However, Go modules may use different comment styles or whitespace variations. Consider using a more robust check, such as checking if 'indirect' is in the comment portion after splitting by '//', or using regex to handle whitespace variations like '//indirect' or '// indirect '.

File operations should specify encoding explicitly to avoid platform-dependent behavior. The open() calls on lines 76, 174, 242, and 400 don't specify an encoding parameter, which means they use the platform default encoding. This could cause issues when parsing files with non-ASCII characters (e.g., package names or comments with unicode characters). Consider adding encoding='utf-8' to all open() calls to ensure consistent behavior across platforms.

The subprocess calls should include shell=False (which is the default) to prevent shell injection attacks. However, the commands constructed use user-controlled package names directly in the command arguments. While using a list (not shell=True) provides protection against command injection, there's no validation that package names don't contain special characters that could cause issues. Consider adding validation for package names to ensure they match expected patterns.

[nitpick] In the _install_pip method, the version handling logic constructs different strings based on whether the version contains operators. However, the condition if not any(op in dep.version for op in ['>=', '<=', '>', '<', '~=', '!=']) results in f"{dep.name}=={dep.version}" when no operators are found, but f"{dep.name}{dep.version}" when operators are present. This means if a version is ">=2.0.0", the resulting string would be "package>=2.0.0" which is correct. However, if a version is stored as just "2.0.1" (extracted from "==2.0.1" on line 140), it would produce "package==2.0.1" which is also correct. The logic seems correct but the code flow on lines 139-143 where exact versions extract just the version number could lead to confusion since the "==" is stripped and re-added later.

The __str__ method in the Dependency class always uses == for version formatting (line 43), but the version field can contain operators like >=, ~=, etc. (as seen in parsing logic on lines 142-143). This means calling str(dep) on a dependency with version ">=2.0.0" would produce "package==>=2.0.0" which is invalid. The __str__ method should handle version specifiers that already contain operators.

Import of 'PackageManager' is not used.

Import of 'pytest' is not used.